Comments on: Portland is an important project, but don’t oversell it

By: Dan Kegel

Dan Kegel — Tue, 17 Oct 2006 22:19:07 +0000

Ian,
I also raised these concerns with Mr. Cherry at OSDN repeatedly.
It’s quite frustrating that they continued overselling Portland for 1.0.
I have encountered confusion about Portland from the developer
community as a result.
On the bright side, a few web sites that covered the 1.0 release
actually got it, and explained what Portland 1.0 was good for.

I think the problem in large part is caused by DAPI being included
in Portland. It really should have been a separate project.

By: Bob Hunter

Bob Hunter — Sat, 14 Oct 2006 08:35:19 +0000

The core problem, in my experience, is the ROI (Return Of Investment). Let me describe it with a concrete case. I spent ten (10) years, part time, in the development of a useful application. The application has been running all along. In those years, due to various updates of the operating system, I had to re-write the application four (4) times. The structure is sound and up to date, but the GUI has been and is still causing me great pains. The application currently runs on linux only. It has a server side, and a clients side. I need them all to run on linux, but also on osx and windows. The step is steep. The problem occurs in other software endevours of mine. I want my software to be free from the mess deriving from non-cross-platform-gui-toolkits-and-related-libraries. When I write a program, I demand it to run natively on linux, osx and windows. So far, I did not manage to fulfill this vivid need. I am also tired of languages that keep getting in the way between my thoughts and their implementation. Object-oriented-Java, with all its calls to libraries, it is an instrument for sad-maso-programming. I appreciate the write-once-run-everywhere philosophy, but why is that it has to be so unnatural, and run fucking slow, excuse my French?. I love Perl. I say it, and I repeat it. I love Perl. The problem is, that it is an interpreted language. So, running a complex perl application in different platforms truly means that each platform must run the whole Perl gamut: the interpreter, and various libraries. By the time you have managed to install, configure, and tune all the elements, you realise you have been working for long hours on a machine just to run one program.

My ideal is
– Perl as main programming language, because it allows all sorts of other languages to occur in the code (SQL, etc.);
– a platform-independent-gui, which I am still in search for;
– a Perl compiler.

Am I asking for too much? It is unrealistic, in the third millennium, to ask for a proper high-level language with a cross-platform-gui and the ability to compile natively in different operating systems?

–bob

By: Ian Murdock

Ian Murdock — Fri, 13 Oct 2006 12:43:07 +0000

Very good point. I often speak about the desire to have more cross platform support in the LSB interfaces, which sometimes leaves people a bit perplexed. The LSB is a Linux thing, right, so who cares about cross platform? Well, the reason we should care is because Linux is usually the second port for an ISV, so the less Linux specific interfaces we provide, the less incremental work the Linux port will be, and the more likely the ISV will be to do the Linux port. So, it’s a very important consideration indeed. -ian

By: Bob

Bob — Fri, 13 Oct 2006 12:34:45 +0000

There is a wide range of applications that could benefit from more user feedback if only they would run on other platforms. Both GTK and QT are eminently linux-only, and developing applications in them leads to linux-only applications. Think of GNU Cash, for example. It only runs on gnome. If you want to run it under KDE, you need to load the GTK libraries. If you want to run it under OSX, you need to load X11 and the GTK libraries. If you want to run it in windows, you need cygwin, x11, and the GTK libraries. The problem is, that native compilation is not possible. PORTLAND may be a step forward on the GTK/QT front, but is Yet-Another-Local-Toolkit. To my judgement, the very best approach is to focus on a cross platform toolkit and GUI library that allows the same source project to be compiled natively on linux, but also on osx, and windows.